The Next Generation Network (NGN) indicates the coming of the age of new generation telecommunication networks. The NGN emerges from the integration of a Time Division Multiplex (TDM) based Public Switched Telephone Network (PSTN) voice network and an Internet Protocol/Asynchronous Transfer Mode (IP/ATM) based packet network, and makes it possible to implement integrated services of audio, video, data and the like over the new generation network.
A schematic structural diagram of the existing NGN network is as illustrated in FIG. 1. A Media Gateway (MG) is used to convert a media stream in a certain type of network to a format required in another type of network. For example, an E1 timeslot in a circuit switched network is converted to a Real-time Transport Protocol (RTP) media stream in an IP network. A Media Gateway Controller (MGC) is used to manage call status and to control bearer resources of the media gateway. A control signal is transmitted between the MGC and the MG, so that the MG can implement establishment, modification and release of a specific media stream, as well as resource management.
In FIG. 1, if bearer networks where the MG1 and the MG2 are located belong to the same private or public network, all IP messages between the MG1 and the MG2 can directly reach each other. If one of the MG1 and the MG2 is located in the public network and another of them is located in the private network, or if the two gateways are located in two different private networks through which an IP message cannot directly reach each other, unidirectional connectivity or non-connectivity of a media stream may arise. The same problem may also arise in a situation where only one of two ends of a media stream is a media gateway and another end is a Session Initiation Protocol (SIP) terminal or an H.323 terminal, is in a Circuit Switched (CS) domain or in a packet network and the like.
Typically, the Network Address (Port) Translation (NA(P)T) technology is adopted for transmitting an IP message between a public network and a private network. For the sake of convenience, both the Network Address Translation (NAT) and the Network Address Port Translation (NAPT) will be referred to as the NAT hereinafter.
There are four types of NAT, i.e., Full Cone, Restricted Cone, Port Restricted Cone and Symmetric. Differences between the four types will be described below by way of an example.
It is assumed that a local media address of a machine A in the private network is 192.168.0.1, an address of an NAT server is 210.21.12.140, a local media address of a machine B in the public network is 210.15.27.166, and a local media address of a machine C in the public network is 210.15.27.140.
Now, the machine A is connected to the machine B through an NAT device, and it is assumed that A (192.168.0.4:5000)->NAT (translated to 210.21.12.140:8000)->B (210.15.27.166:2000). Meanwhile, A has never communicated with C.
For the type of Full Cone NAT, if C transmits data to 210.21.12.140:8000, the NAT transmits the data packet to A (192.168.0.4:5000), because the mapping from 192.168.0.4:5000 to 210.21.12.140:8000 already exists in the NAT.
For the type of Restricted Cone NAT, C cannot communicate with A because A has never communicated with C, and the NAT rejects any action of C of attempting to connect to A. However, B can communicate with 192.168.0.4:5000 of A via 210.21.12.140:8000, and here B can communicate with A via any port. For example, 210.15.27.166:2001->210.21.12.140:8000, and the NAT will transmit it to the port 5000 of A.
For the type of Port Restricted Cone NAT, C cannot communicate with A because A has never communicated with C. Moreover, B can only communicate with 192.168.0.4:5000 of A via its 210.15.27.166:2000 because A has never communicated with other ports of B. This type of NAT is port-restricted.
The above three types can all be referred to as Cone NAT, and they have a common property in that: the NAT translates all packets coming from the same internal address and port to the same external address and port. However, Symmetric is slightly different. Specifically, the NAT translates packets coming from the same internal address and port and going to the same external destination address and port to the same external address and port. By using a different mapping, the NAT translates packets coming from the same address and port and going to a different external destination address and port to a different address and port. As in Port Restricted Cone, a packet can be transmitted only from an external address which has received a packet transmitted by an internal address to the internal address via an NAT mapped address.
Now, Symmetric NAT will be described by way of another example. It is assumed that the machine A has connected to the machine B, and it is assumed that the connection is represented by A (192.168.0.4:5000)->NAT (translated to 210.21.12.140:8000)->B (210.15.27.166:2000). At this time, if the machine A (192.168.0.4:5000) also wants to connect to the machine C (210.15.27.140:2000), a new mapping is generated in the NAT with a corresponding translation possibly of A (192.168.0.4:5000)->NAT (translated to 210.21.12.140:8001)->C (210.15.27.140:2000). At this time, B can communicate with 192.168.0.4:5000 of A only via 210.15.27.166:2000 of B through 210.21.12.140:8000 of the NAT, C can communicate with 192.168.0.4:5000 of A only via 210.15.27.140:2000 of C through 210.21.12.140:8001 of the NAT, and other ports of B or C cannot communication with 192.168.0.4:5000 of A.
The NAT traversal technology refers to that a terminal with a private IP address in the private network accesses to the public network through a Network Address (Port) Translation/Fire Wall (NA(P)T/FW) at an exit. Audio and video applications based on the protocols such as H.323, SIP, Media Gateway Control Protocol (MGCP) and the like need to implement destination addressing by using IP address and port parameters in a signaling message. Therefore, an NAT traversal not only requires translation of port information of the Transmission Control Protocol/User Datagram Protocol (TCP/UDP) layer as well as a source address and a destination address of the IP layer, but also requires translation related address information in an IP packet payload (i.e., signaling).
STUN and TURN are two kinds of NAT traversal approaches commonly used.
The STUN stands for Simple Traversal of UDP Through Network Address Translators, i.e., a simple UDP traversal approach for NAT. An application, i.e., an STUN client, transmits an STUN request message to an STUN server outside an NAT, and upon reception of the request message, the STUN server generates a response message carrying a source port of the request message, i.e., an external port corresponding to the STUN client in the NAT. Then, the response message is transmitted to the STUN client through the NAT, and the STUN client knows its external address in the NAT from contents in the message body of the response message, and puts the external address into a UDP load of a subsequent call protocol to notify the peer end that the local RTP receiving address and port number are the external address and port number in the NAT. A media stream can successfully traverse the NAT because an NAT mapping table entry of the media stream has been created in advance in the NAT through the STUN protocol.
A major advantage of the STUN protocol lies in that no modification needs to be made to the existing NAT/FW device and the STUN approach can be used in a network environment with a plurality of NATs being connected in series. The limitation of the STUN lies in that: the terminal in the private network has to support functions of an STUN client, traversal of the Symmetric NAT type is not supported but an exit NAT of the Symmetric NAT type is typically adopted in an intranet with a relatively high security requirement.
The TURN stands for Traversal Using Relay NAT, i.e., a traversal for NAT by a relay approach. A TURN application model allocates an address and port of a TURN server as an external receiving address and port of a Voice Over IP (VOIP) terminal in the private network, i.e., messages transmitted from the terminal in the private network are all relayed by the TURN server. In addition to the advantage of the STUN approach, this approach also overcomes the drawback of an STUN application being unable to traverse a Symmetric NAT or a similar firewall device, and the TURN also supports a TCP based application. Furthermore, the TURN server controls address and port allocation, and can allocate a pair of RTP/RTCP addresses (an RTP port number plus 1 is an RTCP port number) as a receiving address of an end user in the private network, thereby avoiding arbitrary allocation of RTP/RTCP addresses and port numbers by the exit NAT as in the STUN approach, which leads to the client being unable to receive an RTCP message transmitted from the peer end (the RTCP message is transmitted from the peer end with a default destination port number being an RTP port number plus 1). Unlike the STUN approach that results in an external address in the exit NAT, the TURN approach results in a public network address in the TURN server.
The limitation of the TURN lies in that: the VOIP terminal has to support a TURN client as in the STUN requiring a network terminal. Furthermore, the relay of a media stream via the TURN server may cause an increased delay of a packet and an increased possibility of losing packets. The TURN approach is also referred to as a forward approach of the STUN approach.
An existing H.248 protocol based method for a traversal through an NAT is described below.
In an H.248 message to be transmitted to the gateway 2 in the public network, the media gateway controller specifies that a CPE2 carried in a far end Session Description Protocol (SDP) packet of a RTP endpoint RTP/2 is a private network address of the peer end of a media stream in the private network behind the NAT device.
When a media stream transmitted from the peer end in the private network, i.e., the endpoint with the private network address of the CPE2, passes the NAT, the NAT translates its address into a CPE1, but in the H.248 protocol, the endpoint RTP/2 will transmit the media stream to the private network address CPE2, and this is actually unreachable for the endpoint RTP/2. Consequently, an H.248 signal is added in the H.248.37, and the H.248 signal is issued to the endpoint RTP/2 as an instruction for an NAT traversal. At this time, the endpoint RTP/2 replaces the private network address CPE2 in the far end SDP with the public network address CPE1 of the actually received media stream. The media stream transmitted from the endpoint RTP/2 is transmitted to the CPE1, and according to an address mapping relationship created in advance, the NAT transmits the media stream received by the CPE1 to the address CPE2 in the private network. As can be seen from the above implementation processes, to connect a media stream, it is required that the endpoint in the private network transmits a media stream to the endpoint in the public network first, so that the NAT device is activated to generate address mapping, and according to the source address of the received media stream, the endpoint in the public network determines the destination address to which it transmits media stream.
However, a demand for unidirectional media may arise in a lot of situations. For example, a demand for a ring back tone, a color ring and the like to be played by the peer end, and at this time, for the reason that the called party is not off-hook, the calling party in the private network does not transmit any media stream, so that the calling party in the private network cannot receive a media stream. Furthermore, when a silence detection is activated, there is no media stream transmitted from the private network to the public network if the user in the private network is silent, and the public network cannot transmit a media stream to the private network. In other words, in the specification defined in the H.248.37, the endpoint in the private network has to transmit a media stream to the endpoint in the media gateway of the public network first, otherwise the endpoint in the public network intended to transmit a media stream cannot transmit the media stream to the peer end due to the absence of a public network address to which the NA(P)T maps the private network address of the peer end.
Furthermore, although the STUN server or the TURN server can be used to enable an NAT traversal, a media stream may likely fail to be connected for the types of Restricted Cone, Port Restricted Cone and Symmetric even if the endpoint in the private network has obtained, through the STUN or the TURN, a public network address to which the private network address is mapped. FIG. 2 illustrates a schematic diagram of networking based on the NAT type of Restricted Cone in the prior art, where it is assumed that a local media address of a media gateway 1 is an address B which is mapped to an address A by an NAT, and a local media address of a media gateway 2 is an address X. At this time, even if a media stream transmitted from the media gateway 2 arrives at the address A, it cannot be ensured that the NAT can forward the media stream to the local media address B of the media gateway 1. This is because a preceding STUN message was transmitted from the media gateway 1 to an address Y of the STUN server, and there is no media stream transmitted to the media gateway 2, but for the above three NAT types, a media stream transmitted from the address X can be returned the address B through the NAT only if a message is transmitted from the address B to the address X first.
Furthermore, the NA(P)T has a lifecycle restriction for an address mapping, and the existing address mapping is deleted if it has never been used during the lifecycle. Thus, a media stream cannot be transmitted from the outside of the NA(P)T to the inside of the NA(P)T, and even if a new media stream is transmitted out of the NA(P)T, the NA(P)T may likely map a new public network address for the media stream. A problem may also arise if the peer end uses a previously stored old mapped public network address.
Forwarding a media stream through the TURN server may also encounter similar problems as through the STUN server.
As can be seen in the systems described above, a media device in the private network, such as an MG and various types of terminals and the like, has to transmit a media stream to the peer end first even if the media device has been mapped to a public network address, otherwise a media stream transmitted from the peer end of the media device in the private network first cannot be ensured to arrive at the media device. Furthermore, in these system, an address mapping in the NA(P)T may fail to remain alive in the event that no media stream has passed for a period of time.